Beyond Aesthetic Icing: Designing Geo Tools for Humans
   by Ekta Daryanani and Meghan Hade
   Live captioning by Norma Miller.
   @whitecoatcapxg
   
   
   >> OK, I think we're going to get started.
   >> We're going to get started now. If you guys are having a conversation, if you could take it outside. Just take it outside, guys, come on! Thank you.
   >> Hi. I'm Megan. 
   >> And I'm Ekta. We're going to talk to you today about a project we've been working on at Mapzen, Transitland and about how we're using design to make better, friendlier geo tools.
   >> This is us, at State of the Map last year at the UN in New York, looking super happy amongst all you lovely geo people, with no idea that we'll be up here this year speaking.
   >> I'm a software developer at Mapzen with a background in urban planning.
   >> I am a user experience designer at Mapzen. I most most of my time talking to people and understanding how they use our services and how our tools can better serve their needs.
   >> We're going to start today with this photo. How many people recognize where this photo was taken?
   >> Everybody? Any guesses? That's right, Disney World.
   >> Many of you may have been to a Disney theme park, the Disney theme park experience is pretty unique. A lot of people travel great distances to visit these parks all over the world. These theme parks have been successful for so long because they draw you in and immerse you in the environment. The parks are fantastical. You can sore over London at night in a giant ship. And they're often seemingly magical such as when it snows on a hot December night in Orlando Florida.
   >> So makes all this magic happen? There are people whose job it is to create fun, to bring characters to life, surround with these experiences so we can immerse ourselves by creating the things we see in the movies except that we're in the movies, they're called Imagineers.
   The Disney Imagineer Department, to figure out how to create illusions like fire, outer space or even human-size rodents that people wait in line to see. The imagineers come from a wide variety of backgrounds. Sound artists, project managers, and more. But hold up, why are we talking about Disney so much? Isn't this a talk about designing geo tools? Don't worry, you're not in the wrong talk. Honestly it's hard not to think about theme parks when you're working on a project with name like Transitland. Transitland is an open source project, it started at Mapzen but it is very much a community driven initiative. Transitland is loosely coupled with OpenStreetMap. We conflate things like bus stop locations with OSMiD.
   Transit networks can be fragmented with multiple operators serving one region. For example, these are a few of the operators serving the greater Seattle area. If you wanted to make a map showing all of transit options available here you'd have to gather data from all of these entities. This is our goal, to create a centralized place that is open and accessible to everyone where the data is kept fresh through a healthy ecosystem of users and contributors, a place that is serious and trustworthy, but at the same time easy to use, maybe even a little fun. In short, we wanted to make working with transit data less like this and hopefully more like this.
   [laughter]
   So let's go back to the imagineers for a second. So there's Disney, the imagineers adhere to a set of principles called mickey's 10 commandments. Turns out creating immersive theme park experiences has a lot in common with creating experiences for the web and we've found the imagineers principles to be great guidelines. Five of those ten principles really stood out to us, and we would like to talk about how we applied them to create the Transitland playground.
   Principle 1: Know your audience.
   So we started out by listing all the different types of people who might be interested in contributing to, or using Transitland. Some of them are up here. They're community builders, open data enthusiasts, transit planners, etc.
   We wanted to narrow this list down to meet the needs of a few and meet them well and make them happy. It's a hard decision. Because Transitland is a completely open source project, we decided to focus on these three groups. The community builders, app developers and data enthusiasts. We realized that the involvement of these groups from the very beginning would be essential for creating engagement and start building the community we were imagining.
   >> Next is principle No. 2: Organize the flow of people and ideas.
   Once we had narrowed down the users we would focus on, the next step was to identify their needs and create entry points to Transitland. This is a chart showing the different parts of the Transitland connect. At the center is the data store, the heart of Transitland where the data lives.
   In the data store, we have 346 feeds, most of which have come from community contributors, using the feed registry, you can browse information about all of these feeds, their operators, and also license information.
   Which brings us to the third principle we wanted to discuss.
   >> The third principle is: Communicate with visual literacy. I know it's a little bit weird. But think of it more like a picture is worth a thousand words. The Disney imagineerses really emphasized the use of rich imagery in their work and what better way to do this than in a map. We decided to build what we're calling the Transitland playground to give it a visual language. The playground is an image to query and visualize data on a map. So we looked at this before. This is a snippet of the JSON response for all the transit routes in Seattle: But you get the idea. And this is what the same information looks like represented visually. On a map, right? POOH. Not only does it tell you a better story, but it looks beautiful and it really draws you in.
   Another way to look at Seattle transit data is by operator. These shapes show operators service areas and help us understand transit coverage and then another aspect you can look at is the density of transit stops by area.
   This view shows number of stops as clusters from seven operators. And if you even if you TKOEPBTD know much about Seattle, this map can be incredibly helpful <!0>.
   >> Principle No. 4 is avoid overload. You don't need to make everything available to everyone all at once. In Transitland there's a way to contribute data, there's a way to check when data is available, a way to query and with the playground, a way to view and analyze the data. If you have a lot of data, it helps to use an analogy that people are already familiar with. We wanted to build a tool that allowed for querying Transitland without needing to write a query. We used a mad libs approach.
   At Disneyland you don't know how the ride works. You just suspend your disbelief and. When trying to service the narrative of a large open source system like Transitland, we try and Photoshopped the mechanics of the system into the background. The playground. We intentionally design a very linear way to build queries and look at the data. In this case looking at routes by map view focused right here in Seattle. Straightforward. In this one all the routes S-R serviced by sound transit only. TWUPB of the agencies as you may have heard and then in this one, all the the transit stops right around here, around the university. Each of these maps tell a very different torus story and answer a very different question.
   >> You can use this, too. This kind of approach can be used for any dataset. The idea of a playground doesn't have to be limited to transit data. Any kind of data exploration can use a more visual approach. Projects like overpass turbo and -- so to recap, start by thinking about who will use the thing you are making and what they will get out of it. Don't try to design for everyone. This is especially important for open source projects like OpenStreetMap where a community sense of ownership of a project is essential.
   Don't forget, you are designing for people and often you're designing for a wide variety of people, not just other developers. Organize and present the information in a familiar and understandable way. Using visuals can -P help you make abstract ideas concrete. And imto overcome overload by telling one story at a time.
   So what lessons did we learn from building a playground? If you heard Catherine speak this morning in the awesome keynote, building communities requires care, patience and a lot of listening. The playground has been incredibly helpful to us while importing new data into Transitland. And it's also provided a way for us to visualize the work we're doing in blog posts and in the press. But it's also one of the main pages visited son the Transitland web side and a lot of queries have been run using the playground. But not all of our assumptions were right. For example, one of the features we thought would be important to people was the option to download the data after doing a query. Turns out, not so much. You haven't seen too many data downloads and we are still continuing to investigate why.
   It was important for us to make the playground easy to understand, so we made the building of query super-linear as you saw. You is that right with either routes, stops or operators and then you go deeper as you add filters. The linear format, although easy, ended up being too restrictive and didn't allow for exploration. Also, people expressed the need to be able to interact with individual routes and stops on the map and get more detailed information, but wouldn't do that, and of course the playground is a very sole experience right now. We wanted people to have conversations about what they're looking at and share.
   >> This first version of the playground has been very useful to us internally and has had positive reactions from the transit community. We're modifying the way users navigate data, allowing them to freely explore the connections between operators routes and stops and then focus in and get more detail.
   >> Finally, public transit is just one facet of a transportation network. We're exploring other modes of transportation, such as walking, biking and driving.
   >> So that's it.
   [applause]
   Questions?
   >> What happens from when somebody submits a new feed to when it's fully integrated into the system? What do you do with it?
   >> Repeat the question.
   >> I'll repeat the question. So question is it, what happens if you were to submit a feed, what happens in the process before it would come out in the other end in the playground or the API? We take it in and we do things like conflate it with OSMiDs, and we do some other things like we add, we have a system of labeling things called a one-stop ID and every operator, every route and every stop gets a one-stop ID so you can start to work with those as individual end tis, like one individual bus stop could have a one-stop ID and then that could be shared by multiple routes. So you start to see how different data from other agencies connects and we do some other things like that but we basically just stick with the GTFS format and add a little bit of extra stuff. Does that answer your question? OK.
   AUDIENCE MEMBER:  
    [speaking off mic]
   >> They weren't at that point. That would have been great to have that. We definitely try not to think about people who aren't developers as nontechnical, because they are very technical, people working in transportation are very technical, so we have been talking with a lot of people working in different aspects of industry, so people who work with transit data just to make sure that we're building something useful and also that we're not overlapping with something that has already been built and is out there. So there's been a lot of conversations throughout.
   >> What goes your sourcing process like when you're trying to acquire these feeds and do you have any legal issues getting approvals to use the data?
   >> We haven't had any legal issues, when available we try to get the operator's own license information attached to the feed and you can browse that in part of the website called the feed registry. Anyone can contribute a feed so it doesn't have to come from the agency, but they are all from authoritative sources at this point.
   [applause]